The present invention relates to wireless digital networks, and in particular, to the problem of handling personal firewalls when wireless clients move from one access point to another in a wireless network.
Digital networks have rapidly become the backbone of many enterprises, small and large. The wireless aspects of these networks are becoming more and more important, as is providing seamless service to mobile wireless clients. Such wireless clients may be as simple as an individual operating a wireless handheld scanner taking inventory in a large warehouse, or may be more demanding such as a mobile Wi-Fi telephone user walking between campus buildings.
In some network configurations, it may be advantageous to have wireless access points (APs) operating in bridge mode (as compared to tunnel mode). In bridge-mode operation of a wireless SSID, the AP decrypts arriving wireless packets, converts them from 802.11 packets into 802.3 packets, and bridges those packets out on its wired interface. The AP also applies stateful firewall rules to the traffic for each wireless client, often referred to as a personal firewall.
The stateful firewall may apply a restrictive role for a bridge-client, allowing for only voip (Voice Over IP) or ftp or http traffic, and denying everything all other traffic. In advanced firewalls, sessions such as voip (such as sip/sccp) or ftp begin with the initial control packets exchanged on a well-known port. The payload within these control packets contain information of the data-port to use for the actual data transfer following the control packets. A deep-inspecting stateful firewall can look into those control packets, identify the derived ports to be used later on, and transparently create firewall sessions for these derived sessions to be allowed. This can only be done by snooping the initial control packets.
A client might connect to a different AP's SSID voluntarily due to mobility or involuntarily due to RF or other load-balancing issues. Such a client having any existing derived firewall sessions will have a session drop as the new AP does not know the specific firewall sessions to be allowed. So the call or ftp-transfer as the session might get disconnected and user will have to re-initiate such a call or transfer.
One solution to the problem is to route all client traffic back through the original AP, applying firewall rules at that original AP. This is unwise.
This problem does not exist in tunnel-mode operation of SSIDs, as all firewall enforcement happens on a shared controller, where the sessions are maintained centrally. In such controller-based architectures any amount of mobility of a client from one AP to another will not make the controller lose the session state.
What is needed is a better way of managing personal firewall rules when clients move from one bridge AP to another.